home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
United Public Domain Gold 2
/
United Public Domain Gold 2.iso
/
utilities
/
pu620.dms
/
pu620.adf
/
Utilities
/
CACHEX.LHA
/
CacheX.Docs
< prev
next >
Wrap
Text File
|
1993-05-01
|
10KB
|
246 lines
CacheX V1.0
by Steve Tibbett
INTRODUCTION
CacheX is a simple hard disk cache. Simple because it doesn't buffer
writes, nor get really fancy about caching. But useful because it
will cache anything, even things that the FileSystem buffers will not
cache. It has a friendly user interface, and is a commodity. You can
see the cache hit stats, free the buffers at any time, suspend the
cache, and even tell it to hold onto the buffers it's got, to keep
only specific items in the cache. It caches an entire physical
device, not just individual partitions, though it is limited to only
one physical device. CacheX requires Kickstart 3.0 or later and a
68020 or better processor.
I think it's important to mention that CacheX isn't just a cheap ripoff
of something like HyperCache (which, I believe, is commercial) or any
other cache program. I wrote the first version of CacheX approximately
two years ago, and intended to include it with my bulletin board. I
only recently decided to release it as shareware.
WARNING
CacheX's job is caching hard disk reads. Bugs in CacheX, while none
are known, could cause bad data to be read from your hard disk.
Before trying CacheX, it would be wise to make a backup, especially
on systems that CacheX has not been tested with. CacheX is known to
work with the A3000 "scsi.device", but that is the only device I have
tested it with.
HOW IT WORKS: The Simple Explanation
You tell CacheX the name of a partition that is on the drive you want
to cache, and CacheX figures out the device and unit that that
partition resides on. CacheX then begins caching any reads to that
physical unit - so every partition on that device gets cached.
HOW IT WORKS: Technically
When you tell CacheX the name of a partition to cache, it finds that
partition in the device list, determines what Exec device and unit it
pertains to, and opens that device and unit. It looks at the io_Unit
value that the device provides at OpenDevice() time, and remembers
it. Only IORequests to this device that have the same io_Unit value
will be cached. CacheX then SetFunction's the BeginIO() vector of
the device, and checks every IORequest to see if it's for the unit
we're caching, and if it is, checks to see if it's a CMD_READ. If it
is, it tries to fill the request from the buffers and if it cannot,
it goes to the disk for the read. When the read is done, CacheX then
goes and fills it's own buffers from the data read from the disk.
Upon a CMD_WRITE, it refreshes any of it's own buffers that the data
being written contains.
There are a few potential problems here. One of them is that the
device must use a unique io_Data value for each unit number, or
else CacheX can't tell Unit 0 from Unit 1, for example, and might
return the wrong data. Another potential problem is that
SendIO() effectively turns into DoIO(), since to cache the read,
CacheX has to complete the read before returning from BeginIO().
CacheX is a low-memory-handler, so if a memory panic is about to fail
a memory request, CacheX will step in and dump it's buffers which may
allow the memory request to succeed.
CacheX uses the 3.0 memory pool system to allocate its buffers, and
the buffers are allocated on demand (not all at once) but since they
come from the end of memory, and are in pools of 32 buffers, memory
fragmentation should not be a problem.
The CLIP option is normally set to 32K. When the number of buffers
in a read request is larger than this number of buffers, the read
will not be cached. This is to prevent very large reads from
flushing all the buffers, and to speed things up when reading large
files. (Copying the data from the Read buffer into the Cache buffers
takes an amount of time, and can actually slow down your hard disk
the first time you read something). If you want to cache every read,
then set this value to a number larger than your number of buffers.
FILESYSTEM BUFFERS VS CACHEX BUFFERS
If you are going to use CacheX, you should only use a few FileSystem
buffers (ie, ADDBUFFERS, or changing the Buffers value in HDToolBox).
30 is a good number. Since CacheX is a device cache, not a
filesystem cache, it should happily cache blocks that foreign
filesystems are using, such as the various MSDOS file systems out
there.
The main reason CacheX was written, is because FFS refuses to cache
reads of data bigger than 512 bytes. What this means is that if you
do something like "COPY C:LIST RAM:", it will go to the disk to get
C:LIST every time, no matter how many buffers you have. If you have
a noisy hard drive, and if you are running a BBS, or any other
program that accesses a lot of small data files often, this program
should quieten things down.
THE CACHEX WINDOW
When CacheX is started without the HIDE keyword, it will open a small
window showing you the status of the cache, and give you some buttons
you can push. These are:
CACHE ACTIVE? This checkbox is normally on. When it is
off, CacheX will do nothing.
HOLD BUFFERS? This checkbox is normally off. When it is
on, CacheX will not allocate any new buffers,
keeping any data in the buffers from being
flushed. Writes will still update the buffers
that are already in memory. This option is
used for loading a set of data into the buffers
and then keeping it there.
BUFFERS: This is the number of buffers. Changing the
number of buffers will dump all data currently
in the buffers. You have to hit return in this
gadget to actually change the number of buffers.
RESET STATS This will clear the statistics showing the
number of reads, writes, hits, and the hit
percentage.
HIDE This will close the CacheX window. See below for
more details.
QUIT Terminate CacheX.
HOTKEY: This is the commodities hotkey that you would
use to summon CacheX when it's window is
hidden.
When you HIDE the CacheX window, it will try and open the commodities
library, and if it can, it will close it's window, and set itself up
as a commodity. Caching will continue normally. When you hit the
hotkey, or use Exchange to tell CacheX to open, CacheX will reopen
it's window and remove itself as a commodity.
OPTIONS
CacheX has a number of options, one of which is required (the name of
the device to cache). The options are indicated by the template
"DEVICE/A,BUFFERS/N,HOTKEY/K,HIDE/S,CLIP/N", which are:
DEVICE/A The name of the device to cache. This should be the
name of any partition on the device you want to cache.
BUFFERS/N A number, which is the number of buffers you want.
Each buffer is the size of the block on the device
you're using, normally 512 bytes, but on CDTV (for
example) this would be 2048 bytes. (NOTE that this
program requires 2.04 so it won't work on CDTV).
HOTKEY/K The commodities hotkey specifier, as described in the
2.0 manual, that will bring up CacheX when it is
hidden. This string will normally contain a space,
so must be specified as HOTKEY="the string".
HIDE/S This switch tells CacheX to come up hidden. This is
useful for having it automatically start up, as in
your WBStartup drawer.
CLIP/N This is the CLIP value as described in the technical
description above. It's default value is 64 buffers,
and you can normally leave it set to this.
FAST/S Restrict CacheX to only using FAST memory for it's
cache. If you use a large number of buffers, you can
rely on the low memory handler to dump the buffers when
you run out of memory, restrict it to FAST ram, and
all your unused fast ram will turn into a disk cache.
However, programs that ask for memory in this case may
have their requests for any memory return chip ram since
CacheX's low memory handler doesn't get told about this
situation.
These options can be specified on the command line from CLI, or can
be set as ToolTypes when CacheX is being started from Workbench.
INSTALLATION: Workbench
To run CacheX from Workbench, you can simply double-click on it's
icon. However, you must tell CacheX what device to cache. You do
this by getting Information... on the CacheX icon, and changing the
DEVICE= tooltype to the device name you want to cache, as in
"DEVICE=Work:" (without the quotes). You can set any of the other
options in the same manner. Once you have edited the tooltypes,
double-click on the icon and CacheX should open it's window.
To have CacheX automatically started when you reset your computer,
you need to have it set up so the DEVICE= tooltype is present, and
you also need a "DONOTWAIT" tooltype and the "HIDE" tooltype. When
you have done this, drop CacheX's icon into your WBStartup drawer,
and CacheX should automatically start up next time you reboot. (You
won't know it's there unless you go looking for it, since it will be
hidden).
INSTALLATION: CLI
To run CacheX from CLI, you just have to give the device name.
"CACHEX WORK:" will open the CacheX window and start caching the
Work: device. Any of the options listed above works as you would
expect them to: "CACHEX WORK: HIDE BUFFERS=1000 CLIP=500" would
start CacheX with 1000 buffers, the clip value set to 500, and would
not open the window. Note that if you want CacheX to run in the
background, you have to use RUN >NIL: <NIL: to get CacheX to not keep
the shell window from closing.
THE AUTHOR
This program was originally written for a CDTV project, but ended up
being useful enough to warrant general distribution. Thanks must go
to Jan van den Baard for his excellent GadToolsBox, which was used to
create the user interface.
The author can be reached at:
Portal: SteveX
Bix: s.tibbett
Usenet: SteveX@cup.portal.com
Compuserve: 72627,1325
BBS: 613-731-3419
Home: 613-731-5316 (Evenings)
In that order, if possible, for quick communications. I often don't
have time to answer paper mail in a timely manner, so if you have a
question or bug report, please try and send me email, or just call me.
My mail address is:
Steve Tibbett
2710 Saratoga Pl. #1108
Gloucester, ON
K1T 1Z2 Canada
Program and documentation Copyright 1992 Steve Tibbett. See the
enclosed readme.txt file for more information about CacheX distribution.